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REMARKS 

Claims 42, 45-55, 57, 59-67, 69 and 72-86 stand rejected. Claims 81, 83 and 85 have 
been amended. Claims 82, 84 and 86 have been canceled. The Applicants respectfully request 
reconsideration in view of the foregoing amendments. No new matter is introduced. 

Specification 

Applicants have amended the "Description of the Drawings" section of the specification 
to include a sentence introducing FIG. 5. No new matter is introduced by this amendment. 
Support can be found at least in the specification as originally filed on page 12, line 2 through 
page 13, line 2. Withdrawal of the objection to the specification is respectfully requested. 

Claim Rejections - 35 U.S.C. §103 

Claims 42, 45-55, 57, 59-67, 69 and 72-86 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Du et al (U.S. Patent 6,041,306) in view of Buzaki (U.S. Patent 
5,987,422) in further view of alleged "admitted prior art." 

With respect to claim 81, an automated method is recited for processing a workflow 
among a plurality of activity servers. The method comprises, at each activity server, the steps of: 
(i) obtaining workflow transition information from a common database, the workflow transition 
information defining a sequence of a plurality of activities for a workflow; (ii) retrieving a 
workflow packet from a workflow queue maintained in the common database, the workflow 
packet corresponding to an activity defined in the sequence of activities for the workflow; 
(iii) performing the activity corresponding to the retrieved workflow packet; (iv) determining a 
next activity in the sequence of activities for the workflow from the workflow transition 
information; (v) wherein the next activity is capable of being performed by the activity server, 
performing the next activity without requesting a next workflow packet from the workflow 
queue; and (vi) wherein the next activity is incapable of being performed by the activity server, 
forming the next workflow packet corresponding to the next activity and forwarding the next 
workflow packet to the workflow queue for retrieval by another activity server capable of 
performing the next activity. Similar features are recited in claims 83 and 85, respectively. 
Support for new claim 81, 83 and 85 as amended can be found at least in FIGS. 3, 4 and the 
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specification as originally filed on page 10, line 22 to page 11, line 13, page 13, line 11 to page 
15, line 10, page 16, line 4 to page 19, line 14. 

Accordingly, the claimed invention involves multiple activity servers that together 
process a workflow using workflow transition information obtained from a common database. 
During operation, an activity server retrieves a workflow packet from a common workflow 
queue and performs the activity identified in the workflow packet as well as each subsequent 
activity identified in the workflow transition information until it cannot perform the next activity. 
Once the activity server determines that it is incapable of performing the next activity, the server 
forms a new workflow packet and forwards it back to the workflow queue so that another 
activity server can retrieve and perform at least the next activity within the workflow. Support 
for claims 81, 83 and 85 as amended can be found at least in FIG. 4 and the specification as 
originally filed on page 11, lines 4-13, page 13, line 9 to page 15, line 10, and page 16, line 4 to 
page 18, line 20. 

In contrast, Du et al (U.S. Patent 6,041,306) discuss a distributed workflow management 
system that employs a central workflow engine 20 coupled to a database 21 (Du et al: FIGS. 2, 4; 
col. 5, lines 44-58). The workflow engine 20 functions as a state machine that coordinates 
execution flow of the workflow processes 19 as defined within the database 21 and interfaces 
with external environments. (Du et al: FIG. 4, col. 7, lines 35-44). For example, the workflow 
engine 20 interfaces with resource management modules 28a-c to perform run-time allocation of 
execution resources to a task (Du et al: col. 6, lines 1-6; col. 18, lines 27-47). Specifically, the 
workflow engine 20 sends to the resource manager a message requesting a mapping, including a 
task name, resource role and other pertinent information. If the resource manager can understand 
such information, it performs the requested mapping and replies to the workflow engine with a 
specific resource (Du et al: col. 19, lines 19-27). If the resource manager cannot understand, it 
can simply reject the requested mapping or suggest another resource manager. In response, the 
workflow engine 20 can choose the suggested resource manager or try another. (Du et al: 
col. 19, lines 28-45). 

Thus, the system of Du et al is similar to the prior art that is distinguished in FIG. 2 of the 
present application. In FIG. 2, Applicants distinguish the claimed invention from a resource 
manager 21 that retrieves activities from a database 12 and allocates such activities to 
appropriate activity servers 1 1. As discussed, such a system may reduce contention to the 
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database 12 because only the resource manager 21 lock the database 21. However, the resource 
manager 21 itself is a single point of failure and may become a performance bottleneck. See 
specification as originally filed on page 3, lines 8-14. In contrast, with respect to the claimed 
invention, each of the activity servers are able to access the workflow queue, thereby avoiding a 
single point of failure. Furthermore, since each activity server continues to perform the sequence 
of activities until it cannot perform the next activity, contention to the database created by the 
activity servers accessing the database is reduced. 

Buzsaki (U.S. Patent 5,987,422) does not correct the deficiencies of Du et al in that 
Buzsaki does not disclose an automated method for processing a workflow among a plurality of 
activity servers at all. Rather, Buzsaki is directed at a particular problem in which a workflow is 
blocked pending the receipt of required input. In such instances, Buzsaki stores the current state 
of the workflow and allows other non-blocked workflows to continue. Once the required input 
is received, the blocked workflow continues. (See Buzaki: FIG. 7, Abstract) 

For at least these reasons, claims 81, 83 and 85 are patentable as they are neither 
anticipated nor obvious in view of the prior art of record. 

Furthermore, by virtue of at least their dependency upon claims 81, 83 and 85, 
respectively and the additional features recited therein, claim 42, 45-55, 57, 59-67, 69 and 72-80 
are also patentable. 
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CONCLUSION 

In view of the above amendments and remarks, it is believed that claims 42, 45-55, 57, 
59-67, 69, 72-81, 83 and 85 are in condition for allowance, and it is respectfully requested that 
the application be passed to issue. If the Examiner feels that a telephone conference would 
expedite prosecution of this case, the Examiner is invited to call the undersigned. 


Respectfully submitted, 


Date: December 17, 2008 



Attorney for the Applicants 
Proskauer Rose LLP 
Tel. (617) 526-9655 One International Place 

Fax (617) 526-9899 Boston, MA 021 10 
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